Distributed randomization and supply management in clinical trials

ABSTRACT

A distributed clinical trial system that provides configurability, reusability and integration of randomization and inventory configurations for different clinical trials with various electronic data capture (EDC) systems. The distributed clinical trial system includes a method of dispensing medication in a multi-arm clinical trial. In accordance with the method a subject identifier and a trial identifier are received from an electronic data capture system. The trial identifier indicates the multi-arm clinical trial, and the subject identifier indicates a subject enrolled in the multi-arm clinical trial. An arm identifier is retrieved from a database based on the received subject identifier. The arm identifier indicates an arm in the multi-arm clinical trial to which the subject is assigned. Thereafter, treatment is determined for the arm identifier based on a treatment design previously configured for the multi-arm clinical trial. The treatment includes a set of one or more units of at least one article type.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.14/254,559, filed on Apr. 16, 2014, which is a divisional of U.S. patentapplication Ser. No. 13/157,875, filed on Jun. 10, 2011, which claimspriority to U.S. Provisional Application No. 61/354,200, filed on Jun.12, 2010, which are incorporated herein by reference in theirentireties.

BACKGROUND

1. Field of Technology

The present application relates generally to clinical trial systems.More specifically, the present application is directed to a distributedclinical trial system that provides configurability, reusability andintegration of randomization and inventory management configurations fordifferent clinical trials with various electronic data capture (EDC)systems.

2. Brief Description of Related Art

A clinical trial is performed to, among other things, test the safetyand efficacy of a new drug or treatment (e.g., therapy), and ultimately,to ascertain whether or not a therapy is appropriate for widespreadhuman consumption.

There are generally four phases in the clinical trial. In Phase I, a fewsubjects (approximately 20 to 100) are used to determine toxicity of thetherapy. In Phase II, more subjects (approximately 20-300) are used todetermine efficacy and further ascertain safety of the therapy. In PhaseIII, hundreds to thousands of subjects are used to obtain meaningfulstatistical analysis of the therapy's efficacy. The treatment may becompared to either a placebo or another existing therapy. In Phase IV(post-approval of clinical trial), more testing is performed to evaluatelong-term effects and to evaluate other indications of the therapy.

In a comparative clinical trial, subjects are assigned to multiple armsin order to facilitate analysis in a comparative fashion. For example,subjects assigned to one arm (e.g., “control”) can receive a placebo,while subjects assigned to another arm can receive the medication beingtested. Comparing the results of the therapy in each arm of a multi-armclinical trial provides a measure of the efficacy of the medication intesting the effectiveness of the medication. In another example, armscan also receive various dosages of the medication being tested toevaluate the safety and efficacy of the dosages. Still in otherexamples, some arms can receive another medication against which thesafety and efficacy of the medication being tested can be evaluated.

The subjects of the multi-arm clinical trial are generally randomized(e.g., assigned to the arms of the multi-arm clinical trial in a randomfashion) to avoid biases that may occur in the selection of subjects forthe clinical trial. A bias can be introduced if a subject who is aparticularly well-suited to respond to a new medication—based on certainprognostic factors (e.g., sex, age, prior condition or other factor)—isintentionally assigned to an arm that receives the medication beingtested and not an arm that receives a placebo. This could skew thestatistical analysis and the outcome of the clinical trial to favor themedication being tested.

A bias can further be introduced unintentionally if more subjects havingcertain prognostic factors are randomly, but unevenly, assigned to onearm versus another arm of the clinical trial. Some clinical trials haveattempted to mitigate this bias by attempting to balance certain factorsacross the arms of the clinical trial.

To further mitigate the risk of bias, the multi-arm clinical trials aregenerally single-blinded or double-blinded. The single-blinded clinicaltrial does not reveal the arm assignment to the subject, while thedouble-blinded clinical trial does not reveal the arm assignment to thesubject and to the investigator. Most randomized clinical trials areblinded.

There are currently a number of categories of computerized clinicaltrial management systems that facilitate different aspects of theclinical trial. A first category includes an interactive voice-response(IVR) system or interactive-web-response (IWR) system. Systems in thiscategory typically facilitate enrolment of multiple subjects into aclinical trial and the dispensing of medication during the clinicaltrial. A second category includes an electronic data capture (EDC).Systems in this category typically capture clinical informationconcerning the subjects during the clinical trial.

In most clinical trials, the foregoing systems in these two categoriesare separate and not integrated. In some cases, where integration hasbeen effected, the EDC receives information concerning the enrolledsubjects from the IVR/IWR and randomizes the subjects into arms of theclinical trial. The EDC may also receive information from the IVR/IWRconcerning medication that is administered to the subjects during visitsof the clinical trial. The second system maintains the receivedinformation and other information concerning the clinical trial in aruntime database. Upon completion of the clinical trial, the maintainedinformation is closed out and used to evaluate the medication tested inthe clinical trial.

Typically, a designer writes a specification for the IVR or IWRaccording to the requirements of a particular clinical trial.Thereafter, a developer generally hard-codes or programs the IVR/IWR forthe clinical trial in accordance with the specification. Subsequentrevisions to the specification of the clinical trial require recoding ofthe IVR/IWR. While there has been some integration in clinical trialmanagement, a clinical trial management system that enablesconfigurability, reusability and integration of randomization anddispensing of medication across different trials and various EDCs hasremained illusive.

SUMMARY

In accordance with an embodiment, a method of randomizing subjects in amulti-arm clinical trial is disclosed. In the method, a subjectidentifier and a trial identifier are received from an electronic datacapture (EDC) system. The trial identifier indicates the multi-armclinical trial and the subject identifier indicates a subject enrolledin the multi-arm clinical trial. A randomization design previouslyconfigured for the multi-arm clinical trial is retrieved from a databasebased on the received trial identifier. The subject identifier isassigned to an arm identifier of the multi-arm clinical trial based onthe randomization design. The arm identifier indicates an arm of themulti-arm clinical trial to which the subject has been assigned.

In accordance with an embodiment, a method of dispensing medication in amulti-arm clinical trial is disclosed. In the method a subjectidentifier and a trial identifier are received from an electronic datacapture (EDC) system. The trial identifier indicates the multi-armclinical trial and the subject identifier indicates a subject enrolledin the multi-arm clinical trial. An arm identifier is retrieved from adatabase based on the received subject identifier. The arm identifierindicates an arm in the multi-arm clinical trial to which the subject isassigned. A treatment for the arm identifier is determined based on atreatment design previously configured for the multi-arm clinical trial.The treatment includes a set of one or more units of at least onearticle type.

In accordance with yet another embodiment, a system to randomizesubjects in a multi-arm clinical trial is disclosed. The system includesa randomizer configured to receive a subject identifier and a trialidentifier from an electronic data capture (EDC) system, the trialidentifier indicating the multi-arm clinical trial. The subjectidentifier indicates a subject enrolled in the multi-arm clinical trial.The randomizer is further configured to retrieve randomization designpreviously configured for the multi-arm clinical trial from a databasebased on the received trial identifier. The randomizer is alsoconfigured to assign the subject identifier to an arm identifier of themulti-arm clinical trial based on the randomization design. The armidentifier indicates an arm of the multi-arm clinical trial to which thesubject has been assigned.

In accordance with a further embodiment, a system to dispense medicationin a multi-arm clinical trial is disclosed. The system includes anarticle dispenser configured to receive a subject identifier and a trialidentifier from an electronic data capture (EDC) system, the trialidentifier indicating the multi-arm clinical trial. The subjectidentifier indicates a subject enrolled in the multi-arm clinical trial.The article dispenser is further configured to retrieve an armidentifier from a database based on the received subject identifier. Thearm identifier indicates an arm in the multi-arm clinical trial to whichthe subject is assigned. The article dispenser is also configured todetermine treatment for the arm identifier based on a treatment designpreviously configured for the multi-arm clinical trial. The treatmentincludes a set of one or more units of at least one article type.

In accordance with another embodiment, a machine-readable storage mediumis disclosed. The machine-readable storage medium includes operationalinstructions that, when executed by a processor, cause the processor toreceive a subject identifier and a trial identifier from an electronicdata capture (EDC) system. The trial identifier indicates a multi-armclinical trial and the subject identifier indicates a subject enrolledin the multi-arm clinical trial. The machine-readable storage mediumfurther includes operational instructions that cause the processor toretrieve a randomization design previously configured for the multi-armclinical trial from a database based on the received trial identifier.The machine-readable storage medium also includes operationalinstructions that cause the processor to assign the subject identifierto an arm identifier of the multi-arm clinical trial based on therandomization design. The arm identifier indicates an arm of themulti-arm clinical trial to which the subject has been assigned.

In accordance with still another embodiment, a machine-readable storagemedium. The machine-readable storage medium includes operationalinstructions that, when executed by a processor, cause the processor toreceive a subject identifier and a trial identifier from an electronicdata capture (EDC) system. The trial identifier indicatives a multi-armclinical trial and the subject identifier indicates a subject enrolledin the multi-arm clinical trial. The machine-readable storage mediumfurther includes operational instructions that cause the processor toretrieve an arm identifier from a database based on the received subjectidentifier. The arm identifier indicates an arm in the multi-armclinical trial to which the subject is assigned. The machine-readablestorage medium also includes operational instructions that cause theprocessor to determine treatment for the arm identifier based on atreatment design previously configured for the multi-arm clinical trial.The treatment includes a set of one or more units of at least onearticle type.

These and other purposes, goals and advantages of the presentapplication will become apparent from the following detailed descriptionof example embodiments read in connection with the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation inthe figures of the accompanying drawings in which:

FIG. 1 illustrates a block diagram of an example clinical trial systemconfigured to design, simulate and run at least one clinical trial;

FIG. 2 illustrates a flowchart of an example method of configuring arandomization design for a clinical trial;

FIG. 3 illustrates a flowchart of an example method of performing arandomization simulation of a randomization design generated inaccordance with FIG. 2;

FIG. 4 illustrates a flowchart of an example method of configuring atreatment design for a clinical trial;

FIG. 5 illustrates a flowchart of an example method for setting up aclinical trial via a trial administration interface of an RTSM system ofFIG. 1;

FIG. 6 illustrates a flowchart of an example method of randomizing asubject via a randomizer illustrated in FIG. 1;

FIG. 7 illustrates a flowchart of an example method of assigning asubject to an arm of a clinical trial;

FIG. 8 illustrates a flowchart of an example method of dispensingmedication via article dispenser 164 illustrated in FIG. 1;

FIG. 9 illustrates a flowchart of an example method of randomizing asubject via a trial EDC system illustrated in FIG. 1;

FIG. 10 illustrates a flowchart of an example method of dispensingmedication to a subject via a trial EDC illustrated in FIG. 1;

FIG. 11 illustrates an example webpage to configure a randomizationdesign for a clinical trial;

FIG. 12 illustrates an example webpage to setup and simulate arandomization design for a clinical trial;

FIG. 13 illustrates an example webpage to display simulation results ofone or more simulations executed in FIG. 12;

FIG. 14A illustrates an example webpage to display overall clinicaltrial balance of subject assignments and balance of subject assignmentin trial sites for a simulation;

FIG. 14B illustrates an example webpage to display aggregate statisticalresults across runs of a randomization simulation;

FIG. 15 illustrates an example webpage to configure a treatment designfor a clinical trial;

FIG. 16 illustrates an example webpage to manage article typesillustrated in FIG. 15;

FIG. 17A illustrates an example webpage generated for trial sites in aclinical trial to manage or more trial sites;

FIG. 17B illustrates an example webpage to assign a supply plan to oneor more selected trial sites of the clinical trial;

FIG. 17C illustrates an example webpage to assign a depot to one or moreselected trial sites of the clinical trial;

FIG. 18 illustrates an example webpage generated for management ofsubjects in a clinical trial;

FIG. 19 illustrates an example webpage for management of articleshipments in a clinical trial;

FIG. 20 illustrates an example webpage for managing items of inventoryin a clinical trial;

FIG. 21 illustrates an example webpage for managing an inventory batchlist in a clinical trial;

FIG. 22 illustrates an example webpage for managing logistics supplyplan list; and

FIG. 23 is a block diagram of a general computer system.

DETAILED DESCRIPTION

A distributed clinical trial system and methods are disclosed herein. Inthe following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of example embodiments. It will be evident, however, toone skilled in the art, that an example embodiment may be practicedwithout all of the disclosed specific details.

FIG. 1 illustrates a block diagram of an example clinical trial system100 configured to design, simulate and run at least one clinical trial.For brevity and conciseness, the following description will describe thedesign, simulation and execution of an example clinical trial. It shouldbe noted that multiple clinical trials can be designed, simulated andexecuted, whether contemporaneously or sequentially, in a similarfashion described hereinafter.

The clinical trial system 100 includes a trial administration system104, randomization and trial supply management (RTSM) system 120, and atleast one electronic data capture system (EDC) 176, 190. The clinicaltrial system can also include a trial planner 110, study manager 111,supply manager 112, at least one shipper manager 113, and a plurality oftrial sites 114, 116, 118. The trial planner 110, study manager 111,supply manager 112, shipper manager 113, and trial sites 114, 118, 118can be implemented or operated with respective computing devices. Acommunication network 102 interconnects the foregoing systems 104, 120,176 and computing devices 110-118 in the clinical trial system 100.

The communication network 102 is configured to transmit one or moremessages associated with clinical trial system 100. The transmissionover the network 106 can be accomplished, for example, via TransferControl Protocol/Internet Protocol (TCP/IP), User Datagram Protocol(UDP)/IP, Hypertext Transfer Protocol (HTTP), File Transfer Protocol(FTP), as well as any combination of conventional protocols or protocolsdeployed in the future.

The computing devices 110-118 can include personal computers that areconfigured to communicate via the communication network 102 in order totransmit and receive information concerning the clinical trial. Thecomputing devices 102 can include clients (e.g., Internet Explorer®),which can execute one or more applications and display one or more webpages associated with the clinical trial system 100. The web pages canbe displayed via hypertext markup language (HTML), extensible markuplanguage (XML), extensible HTML, and/or other markup languages, as wellas any other technology now available or to be deployed in the future.

The trial administration system 104 is a centralized system that isconfigured to enable a trial planner (e.g., contract researchorganization) 110 to setup and manage a clinical trial as well as sitesand users associated with the trial sites 114, 116, 118. It should benoted the clinical trial system 100 is configured to support multipletrial planners 110, as well as the setup and management of multipleclinical trials and their associated sites and users.

The trial administration system 104 includes a site setup module 105,user setup module 106, trial setup and manage module 107, inventorydepot setup module 109, and user database 108. The trial setup andmanage module 107 is configured to enable the trial planner 110 tocreate and manage the clinical trial in the clinical trial system 100 inthe RTSM system 120 and/or the EDC system 176, as will be described ingreater detail below with reference to the RTSM system 120 and the EDCsystem 176. At setup, the trial setup and manage module 107 isconfigured to generate a trial ID associated with clinical trial and totransmit the trial ID, site IDs (set up via site setup 105) to the RTSMsystem 120 and the EDC system 176.

The trial administration system 104 is further configured toauthenticate the users to use the clinical trial system 100, toauthorize certain of the users to access certain trials and within thesetrials to access certain resources (e.g., systems or subsystems) in theclinical trial system 100, and to interconnect the constituent systemsand computing devices 120, 176 and 110-118 during setup and runtime ofthe clinical trial via the communication network 102.

The site setup module 105 is configured to enable the trial planner 110to setup example trial sites 114, 116, 118 (site IDs) and associatethese trial sites with the clinical trial and one or more users set upvia the user setup module 106.

The user setup module 106 is configured to enable the trial planner 110to setup users who are associated with the trial planner 110, at leastone shipper manager 113, trial sites 114, 116, 118, users of any otherrole in the clinical trial, as well as their authorizations in theclinical trial system 100. Usernames, passwords and authorizations ofusers in the clinical trial system 100 can be maintained by the trialadministration system 104 in the user database 108.

The inventory depot setup module 109 is configured to enable the trialplanner 110 to setup one or more depots 115 associated with trial sites114-118 and shipper managers 113 in the clinical trial system 100. Eachdepot 115 can be associated with one or more of the trial sites and oneor more of the shipper managers 113. For clarity and brevity, one depot115 is associated with one shipper manager 113 and trial sites 114-118.

The RTSM system 120 is configured to enable the trial planner 110 toselect and design randomization and treatment design for the clinicaltrial, as well as simulate the selected randomization design. The RTSMsystem 120 includes a trial administration interface 121, user interface122, EDC interface 123, design and simulation subsystem 124, and runtimesubsystem 156.

The trial administration interface 121 is configured to interconnect thetrial administration system 104 with the RTSM system 120 and receivesthe trial ID and site IDs for the clinical trial from the trialadministration system 104. Further, the user interface 122 is configuredto enable the trial planner 110 to access the design and simulationsubsystem 124 in order to select/configure a randomization design andtreatment design associated with the clinical trial and to simulate therandomization design. The design can be simulated and configured toreduce the number of subjects necessary for the clinical trial. Afterthe selection/configuration of the randomization design and treatmentdesign, the user interface 122 is configured to store the received trialID and indications of the selected/configured randomization design andtreatment design in a runtime database 158 of the runtime subsystem 156.

The design and simulation subsystem 124 is configured to enable thetrial planner 110 via the user interface 122 to select and configure arandomization design and treatment design for the clinical trial (trialID) and to simulate the randomization design. The design and simulationsubsystem 124 includes a randomization designer 126, randomizationsimulator 138, treatment designer 148, and randomization and articledatabase 154.

The randomization designer 126 is configured to allow the trial planner110 to configure and save a randomization design (including a pluralityof randomization metrics) for the clinical trial (trial ID). FIG. 11illustrates an example webpage generated by the randomization designer126 to allow the configuration of a randomization design for theclinical trial. The randomization designer 126 includes an arm andarm-subject ratio module 128, randomization factor module 130, factorweight module 132, randomization-second-best-probability module 134 andstrata module 136.

The arm and arm-subject ratio module 128 is configured to allowdesignation of arms in the clinical trial and ratio of subjects amongthe arms of the clinical trial. For example, if there are two arms witha ratio of 1:2, respectively, the RTSM system 120 will attempt to assignsubjects to these arms such that 1/3 of the subjects are assigned to thefirst arm and 2/3 of the subjects are assigned to the second arm.

The randomization factor module 130 is configured to allow designationof randomizing/balancing factors for the clinical trial. For example,randomizing factors such as age, sex, metabolic rate, and/or otherfactors associated with the assignment of the subjects to the arms inclinical trial can be designated.

The factor weight module 132 is configured to allow designation ofrandomization weights for the randomizing factors designated by therandomization factor module 130.

The randomization-second-best-probability module 134 is configured toindicate a probability percentage associated with an assignment of asubject to a second-best arm, mitigating a deterministic assignment aswill be described below in greater detail with reference to FIG. 7.

The strata module 136 is configured to allow designation of two or morestates for each randomization factor. For example, for a randomizingfactor of “sex”, two states would be defined, i.e., “male” and “female”.As another example, for a randomizing factor of “age”, multiple statescould be designated, such as, 25-35, 35-45, 45-55, 55-65 and greaterthan 65.

Once the randomization design has been configured using modules 128-136,the trial planner 110 can save a randomization design for the clinicaltrial (trial ID) via the randomization designer 126, such as via a“save” indication, to the randomization and article database 154.

The randomization simulator 138 is configured to allow the trial planner110 simulate the saved randomization design for the clinical trial. Oneor more simulations can be generated, saved and executed. Thesimulations and their results can be saved in the randomization andarticle database 154. FIG. 12 illustrates an example webpage generatedby the randomization simulator 138 to setup and simulate therandomization design for the clinical trial. The simulation can be usedto validate that the randomization design meets the requirements of theclinical trial, including minimizing the number of subjects that arerequired to be enrolled in the clinical trial. The randomizationsimulator 138 includes a simulation setup module 140, execution module142, result module 144, and analysis module 146.

The simulation setup module 140 is configured to receive simulationmetrics from the trial planner 110 for the randomization simulations,such as, a number of simulation runs, number of subjects, number ofsites and strata distribution ratios (collectively indicating aprobability that a simulated subject will be generated as belonging to astratum).

The execution module 142 is configured to execute the simulationsaccording to the received simulation metrics. The execution module 142generates simulation runs as indicated by the received number ofsimulation runs, and within each generated simulation run generatessimulated subjects as indicated by the received number of subjects. Eachsimulated subject is generated as belonging to a trial site and stratain a probabilistic process controlled by the remaining receivedsimulation metrics, respectively. For example, if there are two stratawith distribution ratios 1:2, respectively, the process will accord a1/3 probability of generating a simulated subject belonging to the firststratum, and 2/3 probability of generating the simulated subject asbelonging to the second stratum.

Once the simulated subject is generated, the execution module 142communicates with a randomizer 162 of FIG. 1, using algorithmicinterface 160, to randomize the simulated subject to an arm inaccordance with the randomization metrics of the randomization designthat was configured via the randomization designer 126 describedhereinabove.

The result module 144 is configured to display the results of theexecuted simulations. The displayed results can include for eachsimulation executed, its simulation metrics, start time and end time,total execution time. An example simulation results webpage is shown inFIG. 13. The displayed simulation results can show for each of the runsof the simulation the distribution of the subjects across the trial armswithin each of the following subject groups: (i) all the subjects in theparticular run; (ii) for each site, the subjects that belong to thatsite; (iii) for each state of each factor, the subjects that belong tothat state of that factor; (iv) for each stratum, the subjects thatbelong to that stratum.

The analysis module 146 is configured to aggregate and analyze theresults produced by the execution module 142 for each run, and presentstatistically significant quantities, such as a mean, standarddeviation, minimum number of subjects, and a number of times that aparticular group of simulated subjects was out of balance.

The design selector 147 is configured to allow the trial planner(designer) 110 to import the design of an existing study into a newstudy or to link the new study to an existing study's design. The designselector 147 includes a copy design module 151 and share design module153. The copy design module 151 provides the ability to import thedesign of an existing study into a new study. Changes to the design ofthe new study do not affect the existing study, and vice versa. Theshare design module 153 provides the ability to link the new study to anexisting study's design so that any changes in the existing study designwill affect the design of the new study, and vice versa.

The treatment designer 148 is configured to allow the trial planner 110to configure and save a treatment design for the clinical trial (trialID). FIGS. 15 and 16 illustrate example web pages generated by thetreatment designer 148 to configure the treatment design for theclinical trial. The treatment designer 148 includes an article module150 and arm treatment module 152.

The design reporting module 149 is configured to deliver to trialplanners 110 or study managers 111 a detailed report concerning thecurrent study design. The report enumerates and explains study arms andratios, randomization factors and strata, randomization weights,randomization probabilities and article types and treatments. Otherfactors, features or aspects associated with the study design asdescribed herein can be included in the report.

The article module 150 is configured to receive from the trial planner110 a definition or indication of one or more article types andassociated dispensation metrics for those article types. For example,“article type 1” can be defined as “Aspirin×325 mg×1 pill”. As anotherexample, “article type 2” can be “Aspirin×81 mg×1 pill”. Thedispensation metrics for trial sites associated with defined articlescan include also indications of the minimal number of days betweendispensation and expiration of the article. Additional dispensationmetrics associated with the article types can be provided.

The arm treatment module 152 is configured to receive from the trialplanner 110 a treatment associated with of each arm of the clinicaltrial. The treatment is composed by the indication of an “article type”and a “number of units” for the article type. For example, arm 1 canreceive a treatment composed of 1 unit of “article type 1”, arm 2 canreceive 1 unit of “article type 2”, while arm 3 can receive 1 unit of“article type 1” and 2 units of “article type 2”.

While the foregoing examples are intended to illustrate the articlemodule 150 and the arm treatment module 152, it should be understoodthat the trial planner 110 can configure various articles (differentmedications and dosages), as well as treatments composed of differentunits of these articles, via the treatment designer 148.

The randomization and article database 154 maintains the randomizationdesign configured via the randomization designer 126, the results of thesimulations generated by the randomization simulator 138, as well as thetreatment design configured via the treatment designer 148.

The runtime subsystem 156 is configured to provide trial management, aswell as randomization and article dispensing for subjects of theclinical trial. The runtime subsystem includes a runtime database 156,an algorithm interface 160, and a trial manager 166. The runtimedatabase 156 maintains data for the clinical trial, including its trialID, site IDs, randomization design, treatment design, as well as livedata including subject records, inventory item and batch records, andshipment records for the clinical trial.

The EDC interface 123 is configured to interface with one or moredifferent trial EDCs to receive requests to assign (randomize) subjectsto the arms of the clinical trial and to indicate a set of units ofarticles types to dispense to the subjects. The EDC interface 123interfaces with an algorithm interface 160 that includes a randomizer162 and an article dispenser 164, which assign the subjects to the armsof the clinical trial and identify the units if article types,respectively. The algorithm interface 160 also includes a shipping(shipper) algorithm 165. The EDC interface 123 returns the subjectassignments and unit identifications to the requesting trial EDCs.

The randomizer 162 is configured to receive randomization data (e.g.,trial ID, site ID, subject ID, and state of the subject ID in each ofthe factors defined in the randomization design) from a randomizationcustom function (CF) 186 of the trial EDC 176, as will be describedgreater detail below with reference to the trial EDC 176. As describedhereinabove, the randomizer 162 is also configured to receive simulatedrandomization data (e.g., simulated trial ID, site ID, subject ID, andstate of the subject ID in each of the factors defined in therandomization design) from the randomization simulator 138.

The randomizer 162 is further configured to retrieve the randomizationdesign for the trial ID. In one embodiment, the randomizer 162 retrievesan indication of the randomization design associated with the trial IDfrom the runtime database 158 and further retrieves the randomizationdesign from the randomization and article database 154 based on theindication. In another embodiment, the randomizer 162 is configured toretrieve the randomization design for the simulated trial ID from therandomization and article database 154.

The randomizer 162 is also configured to assign (randomize) the subject(subject ID) to an arm (arm ID) of the clinical trial (trial ID) basedon the randomization design, as well as to store the trial ID, site ID,subject ID, states of the factors, and arm ID assignment to the runtimedatabase 158. Subject assignment to the arm of the clinical trial isdescribed in greater detail below with reference to FIG. 7. Therandomizer 162 is further configured to transmit a randomizationindicator to the randomization CF 186 of the trial EDC 176, whichindicates that the subject has been assigned (randomized) in theclinical trial. For simulations, the randomizer 162 is similarlyconfigured to store simulated data and assignments to the randomizationand article database 154 and to return a randomization indicator to therandomization simulator 138.

The article dispenser 164 is configured to receive article dispense data(e.g., trial ID, site ID, subject ID, and visit ID) from a dispense CF188 of the trial EDC 176, as will be described greater detail below withreference to the trial EDC 176. The article dispenser 164 is furtherconfigured to retrieve an arm ID for the subject ID from the runtimedatabase 158, which indicates to which arm the subject ID is assigned.The article dispenser 164 is further configured to determine a treatment(e.g., set of one or more units of articles) for the arm ID from thetreatment design associated with the clinical trial ID in therandomization and article database 154. Further, the article dispenser164 is configured to determine whether there are sufficient units ofarticles in the inventory associated with the trial ID that comply withdispensation metrics for the site ID. If so, the article dispenser 164transmits a set of units of the articles to the dispense CF 188 of thetrial EDC 176 for dispensing to the subject ID. The article dispenser164 is also configured to adjust the inventory for the trial ID based onthe dispensed set of units to the subject ID.

The logistics interface 125 interfaces the study managers 111 and supplymanagers 112 with algorithm interface 160. More specifically, thelogistics interface 125 allows study managers 111 and supply managers112 to set “supply plans” for trial sites 114-118.

A supply plan determines the triggers and supply levels that the shipperalgorithm 165 will aim to maintain for the trial sites (e.g., trialsites 114-118) that are assigned that supply plan. Different supplyplans can be defined for different trial sites. A supply plan defineshow trial sites associated with that supply plan will be supplied. Eachsupply plan defines: (i) a unique name; (ii) four parameters for eacharticle type, (a) minimal number of days between shipping andexpiration, (b) initial site stocking level, (c) resupply thresholdlevel, and (d) resupply stocking level; and (iii) a parameter that setsthe supply plan as the default for the study.

As will be described in greater detail with reference to FIG. 22, thelogistics interface 125 provides several user interface screens tomanage supply plans: (i) the supply plan list interface; and (2) thesupply plan manage interface. The supply plan manage interfaceillustrates the details of a specific supply plan and is used foradding, changing and deleting supply plans. The supply plan listinterface shows the list of supply plans.

The shipping algorithm 165 is executed periodically or upon request. Insome embodiments, the shipment module 172 via algorithm interface 160can periodically (e.g., every night) execute the shipping algorithm 165.Alternatively or in addition, shipper managers 113, study managers 111and supply managers 112 can also manually execute the shipping algorithm165 from the shipments user interface (e.g., FIG. 19), such as via thelogistics interface 125.

When the shipping algorithm 165 is executed, for every trial site andevery article type, it compares the number of items of that article typethat are either available at trial site (let a1 be the number of suchitems), or are currently being shipped to that site (let a2 be thenumber of such items) or allocated to be shipped to that trial site (leta3 be the number of such items), with the threshold number for thatarticle type (let t be the number of such items) as defined in the trialsite's supply plan.

Accordingly, if a1+a2+a3≦t, the shipping algorithm 165 will allocate newitems of that article type that are available for shipping at the trialsite's associated depot 115 to a new shipment. Where r is the resupplytarget set for that article type in the trial site's supply plan, theshipping algorithm 165 will allocate r−(a1+a2+a3) items for shipment. Itshould be noted that the shipping algorithm 165 will only allocate to atrial site items that have an expiry date later than the “minimal numberof days between shipping and expiry” value set in that trial site'ssupply plan. The shipping algorithm 165 will also prefer to ship itemswith sooner expiry days rather than later ones, as long as the itemssatisfy the restrictions above.

The shipping algorithm 165 will traverse through all the article types,and once done, all the items allocated for shipment for the specifictrial site will be collected into a new shipment record. The shippingalgorithm 165 can then issue (and transmit) an email to the supplymanagers 112, as well as any shipper manager 113 associated with a depot115 (associated with the trial site), alerting them to the existence ofa new pending shipment (shipment record).

By following a link provided in such email, a shipper manager 113associated with the depot 115 can access the shipment record, review thelist of items requested for shipping, ship those items, and then confirmthe shipment. The shipper manager 113 can also dissolve the shipment,resetting the status of the items in the shipment to “available forshipment” once again. It should be noted that dissolving a shipmentassigns the inventory items in that shipment to an “available forshipment” status at the depot 115 with which their batch is currentlyassociated. For example, if a request for shipment s is created fordepot d1, inventory item i is included in this shipment and item ibelongs to batch b (this can only happen if b is assigned to depot d1 aswell). In this example, assume that after the shipment request s iscreated, batch b is reassigned to depot d2 Thus, if shipment s isdissolved, item i is marked as “available for shipping” at depot d2.

Moreover, the shipping algorithm 165 is also configured to issue emailnotifications for shipments that have been requested as well as whendepots 115 run out of stock.

The trial manager 166, which can be accessed via user interface 122, isconfigured to provide management functionality for the different usersof the clinical trial system 100, such as of the trial planner 110,study manager 111, supply manager 112 and shipper manager 113, andpersonnel from trial sites 114-118. The trial manager 166 includes asite module 168, subject module 170, shipment module 172, and inventorymodule 174.

While the trial planner 110 generally configures the trial sites viasite setup 105 of the trial administration system 104, and configuresdepots 115 via inventory depot setup 109, the site module 168 isconfigured to enable the study manager 111 to manage RTSM parametersassociated with each of the trial sites in the clinical trial. FIG. 17illustrates an example webpage generated by the site module 168 for theclinical trial, including one or more trial sites (e.g., trial sites1114, 116, 118). For each trial site, site module 168 is configured toallow setup of a supply plan and assignment of a depot (e.g., depot 115)for the trial site, as well as to present a number (site ID), number ofsubjects randomized to the trial site, number of shipments to the trialsite and number of inventory items at the trial site. The site module168 is further configured to enable the study manager 111 toactivate/deactivate drug shipping from the depot (e.g., depot 115) toeach of the trial sites (e.g., trial sites 114-118).

In addition, supply plans play an important role in the site module 168.The site module 168 is configured to assign and provide for each sitethe supply plan it is associated with and can assign trial sites to asupply plan “en mass”.

The subject module 170 is configured to enable the study manager 111 andtrial sites 114-118 to manage the subjects in the clinical trial. FIG.18 illustrates an example webpage generated by the subject module 170for the clinical trial, including one or more subjects (subject IDs). Inone embodiment, for each subject ID, the subject module 170 isconfigured to provide stratum, trial site (site ID), trial arm (arm ID),arm selection method and when the subject was assigned (randomized) tothe trial arm. The actual data of the clinical trial that is displayedby the subject module 170 to various users depends on theirauthorizations (or permissions) provided by the user setup module 106 ofthe trial administration system 104.

Importantly, these permissions determine the scope of the user access tothe subject population in the clinical trial. For example, the studymanager 111 could view a list of subjects enrolled in multiple trialsites, whereas trial site 114 could only view subjects belonging to thattrial site. Furthermore, different users can have different display forthe same subjects. For example, the study manager 111 may have access toview arm assignments of subjects, while other users, such as trial sites114-118, may not have such access to arm assignments.

The design update module 171 is configured to enable the trial planner(designer) 110 to modify or update the study design at runtime, i.e.,after the study has already gone live. The design update module allowsmodification the ratios of study arms via the arm ratios module 128,weights of the randomization factors via the factor weight module 132,probability percentage via the randomization probability module 134, andminimal time between dispensation and expiry via the article module 150.

The shipment module 172 is configured to enable the supply manager 112,trial sites 114-118, as well as shipper manager 113 to manage thearticle shipments in the clinical trial. FIG. 19 illustrates an examplewebpage generated by the shipment module 172 for the clinical trial,including one or more shipments. Each of the one or more shipments caninclude a name of the shipment, trial site (site ID), date shipment wasshipped from depot by shipper manger, date the shipment was received atthe trial site, a tracking number associated with the shipment, andunits of articles shipped in the shipment. The shipment module 172includes “waste and replace” functionality configured to allow theshipper manager 113 to mark items reserved for the shipment as wasted,and request replacements for inclusion in the shipment. Permissions ofthe users configured via the trial administration system 104 also affectthe data displayed by the shipment module. The permissions determine thescope of user access to the shipments in the clinical trial. Forexample, trial site 114 will be able to see shipments destined for trialsite 114, but will not be able to see shipments destined for trial site116. Similarly, the shipper manager 113 can see just those shipmentsoriginating from a depot 115 with which the shipper manager 113 isassociated, and not shipments originating from others depots (notshown).

The unblinding module 173 is configured to authorize subject unblindingor item unblinding for subjects or items, respectively. In most clinicaltrials subjects remain “blinded”, e.g., without disclosure to whichstudy arm subject were randomized, and to which article types inventoryitems belong. The unblinding module 173 allows authorized users to getaccess to this information. This action can be audited by the auditmodule 169 as described below.

The audit module 169 is configured to allows the study manager 111 toaudit or view any changes that were made to the study design, to thesupply plans, to the site's associated depots or supply plans as well asany changes that happened to any subject, inventory item, inventorybatch or shipment record.

The inventory module 174 is configured to enable the trial planner 110,study manager 111, shipper manager 113, and trial sites 114-118 tomanage the inventory associated with the clinical trial. FIGS. 19 and 20illustrate example web pages generated by the inventory module 174 forthe clinical trial. For example, FIG. 19 illustrates a general inventoryitem list, while FIG. 20 illustrates a list of batched items uploaded bythe inventory module 174 via user interface 122, from the trial manager111 or shipper manager 113, into the clinical trial inventory in theruntime database 158. Again, permissions of users determine the scopeover the list of items available and information available for each itemto the users.

The EDC system 176 is configured to receive and maintain data associatedwith a clinical trial from the trial sites 114, 116, 118 and the RTSM120. The EDC system 176 can be any clinical trial data capture systemthat can execute a custom function described herein to communicate withthe RTSM system 120. The EDC 176 includes trial database 178, trialsetup subsystem 180 and trial runtime subsystem 182. These subsystems ofthe EDC system 176 are not exhaustive, but are meant to illustrate theintegration of the RTSM system 120 and EDC system 176, which isdescribed in this application. Accordingly, one or more additionalsubsystems or components can be included in a particular EDC system 176.

The trial database 178 maintains data associated with the clinicaltrial, such as subjects, trial sites and dispensed units of articles, aswell as clinical information collected for the subjects during theclinical trial. The trial setup subsystem 180 is configured to receive atrial ID and site ID associated with the clinical trial from the trialadministration system 104, when a trial site (e.g., trial site 114) logsinto the trial administration system 104. The trial setup subsystem 180is further configured to store and maintain the received trial ID, siteID and associated trial data in the trial database 178.

The trial runtime subsystem 182 is configured to receive data of asubject from a trial site (e.g., trial site 114) and to enroll thesubject into the clinical trial. It is to be noted that multiplesubjects can be enrolled from each of the trial sites 114, 116, 118. Thetrial runtime subsystem 182 is further configured to randomize theenrolled subjects in the clinical trial and to dispense appropriatemedication to the subjects via the RTSM system 120. The trial runtimesubsystem 182 includes a subject data input module 184, randomization CF186, and dispense CF 188.

The subject data input module 184 is configured to receive dataassociated with a subject to be enrolled into the clinical trial, forexample, from trial site 114. This data can include the subject'senrollment consent form and personal data associated with the subject(e.g., name and contact information). The received data also includesstates of the subject in each of the one or more factors required forrandomization of the subject in the clinical trial, as describedhereinabove with reference to the randomizer 162 of the RTSM 120. Itshould be noted that the states of the factors can also be received bythe subject data input module 184 via integration of the EDC system 176with other clinical information systems that collect subject informationat the start or during the clinical trial. The subject data input module184 is further configured to assign the enrolled subject a subject IDand to add a new subject record for the subject ID to the trialdatabase, which includes the trial ID, site ID, states of the factorsand any other information received for the subject from the trial site(e.g., trial site 114).

The randomization CF 186 is configured to randomize a subject ID.Specifically, the randomization CF 186 determines whether randomizationof the enrolled subject (subject ID) has been triggered via inputreceived by the subject data input module 184. The randomization triggercan be automatically determined based on whether all required input forrandomization has been received for the subject ID (e.g., from trialsite 114) or can be user-initiated from the trial site (e.g., trial site114). Once triggered, the randomization CF 186 is configured to convertthe trial ID, site ID, subject ID and the states of the subject in thefactors to RTSM randomization data. The randomization CF 186 is furtherconfigured to transmit the RTSM randomization data to the EDC interface123 of RTSM system 120 and to receive a randomization indicator thatindicates successful assignment (randomization) of the subject ID to anarm of the clinical trial. The randomization CF 186 stores therandomization indicator to the record of the subject ID in the trialdatabase 178.

The dispense CF 188 is configured to determine the number of units ofarticles to dispense to the subject ID at a visit to the trial site(e.g., trial site 114). The visit can be at the same time the subject IDis enrolled and randomized in the clinical trial and/or a later visit,being indicated by a visit ID. The visit ID can be any alphanumericstring that uniquely identifies the dispensing (e.g., a date indicator).The dispense CF 188 determines whether dispensing to the subject ID hasbeen triggered by the trial site (e.g., trial site 114), such as viauser-initiated input. Once triggered, the dispense CF 188 adds adispense record for the subject's record associated with the subject ID,which includes a dispense indication. The dispense CF 188 is configuredto convert the trial ID, site ID, subject ID visit ID to RTSM dispensedata. The dispense CF 188 is further configured to transmit the RTSMdispense data to the EDC interface 123 of RTSM system 120 and to receivea set of one or more units indicators to be dispensed to the subject ID.The dispense CF 188 stores the dispense unit indicators to the visitrecord of the subject ID in the trial database 178.

FIG. 2 illustrates a flowchart of an example method 200 for configuringa randomization design for a clinical trial. The method 200 starts atoperation 202 where the trial planner 110 invokes or executes therandomization designer 126 to configure the randomization design, asillustrated in FIG. 1. At operation 204, a number of trial arms arereceived for a clinical trial. Zero or more randomizing factors, such asage, sex and/or one or more other factors are received at operation 206.At operation 208, weights associated with clinical trial, trial site andstrata, as well as with the randomization factors of operation 206 arereceived. At operation 210, a second best probability percentageassociated with the randomization of subjects is received. Two or morestrata states are received at operation 212 for each of therandomization factors received at operation 206. At operation 214, therandomization design with the received design metrics is saved, forexample, in the randomization and article database 154.

FIG. 3 illustrates a flowchart of an example method 300 for performing arandomization simulation of a randomization design generated inaccordance with FIG. 2. The method 300 starts at operation 302 where thetrial planner 110 invokes or executes the randomization simulator 138 toperform the randomization simulation, as illustrated in FIG. 1. Atoperation 304, simulation metrics for the randomization simulation arereceived. The simulation metrics can include number of execution runs,subjects and trial sites, as well as strata distribution. At operation306, the randomization simulation is executed according to the receivedsimulation metrics based on the randomization design generated in FIG.2. At operation 308, the simulation results of the simulation are saved,such as in the randomization and article database 154 illustrated inFIG. 1.

At operation 310, a determination is made as to whether therandomization simulation yielded satisfactory results for therandomization design. The reasons for determining that the whether thesimulation results are satisfactory can include, but are not limited to,high frequency of imbalance among runs at one or more group of subjects(e.g., group of subjects in the entire clinical trial, groups ofsubjects at trial sites, groups for states of subject factors, andgroups for subject strata), too few or too many subjects assigned to atleast one arm within one or more of the groups, or too high variabilityamong the runs.

If it is determined that the simulation results were satisfactory atoperation 310, the method ends at operation 318. However, if it isdetermined that the simulation results were not satisfactory atoperation 310, the method 300 continues at operation 312, where adetermination is made as to whether the randomization design should beupdated. If it is determined that the randomization design should not beupdated at operation 312, the method continues at operation 304 toreceive updated simulation metrics for the randomization simulation, andthe simulation is executed according to the updated simulation metricsand the previously saved randomization design at operation 306.

If it is determined that the randomization design should be updated atoperation 312, the method continues at operation 314 to invoke method200 of FIG. 2 for updating the randomization design (design metrics ofthe randomization design). At operation 316, a determination is madewhether simulation metrics for the randomization simulation should beupdated.

If it is determined that simulation metrics should be updated atoperation 316, the method 300 continues at operation 304 to receivesimulation metrics for the randomization simulation. At operation 306,the simulation is executed according to the updated simulation metricsand the updated randomization design.

However, if it is determined that simulation metrics should not beupdated at operation 316, the method continues at operation 306 toexecute the randomization simulation according to the previouslyreceived simulation metrics and the updated randomization design.

FIG. 4 illustrates a flowchart of an example method 400 for configuringa treatment design for a clinical trial. The method 400 starts atoperation 402 where the trial planner 110 invokes or executes thetreatment designer 148 to configure the treatment design, as illustratedin FIG. 1.

At operation 404, definitions of one or more article types andassociated dispensation metrics are received for the clinical trial. Forexample, “article type 1” can be defined as “Aspirin×325 mg×1 pill” and“article type 2” can be “Aspirin×81 mg×1 pill”. The article typeindicates the medication, dosage, and pill count number. A treatmentassociated with each arm of the clinical trial is received at operation406. The treatment is composed by the indication of an “article type”and a “number of units” for the article type. For example, arm 1 canreceive a treatment composed of 1 unit of “article type 1”, arm 2 canreceive 1 unit of “article type 2”, while arm 3 can receive 1 unit of“article type 1” and 2 units of “article type 2”.

At operation 408, the treatment design is saved, such as in therandomization and article database 154 illustrated in FIG. 1.Thereafter, the method 400 ends at operation 410.

FIG. 5 illustrates a flowchart of an example method 500 for setting up aclinical trial via the trial administration interface 122 of the RTSMsystem 100 of FIG. 1. The method 500 starts at operation 502 where thetrial planner 110 logs into the trial administration system 104. Atoperation 504, trial and site information associated with clinical trialare received from the trial administration system 104. The receivedinformation can include a trial ID that identifies the clinical trialand site IDs associated with the trial ID that identify the trial sitesof the clinical trial.

At operation 506, a randomization design and treatment design areselected for the clinical trial (trial ID) from one or more savedrandomization designs and treatment designs. The trial ID and associatedselection of the randomization and treatment design are stored, such asin the runtime database 158 of the runtime subsystem 158, as operation508. At operation 510, an inventory associated with a depot 115 isgenerated for the trial ID according to the selected treatment design,such as in the runtime database 158. An inventory batch that indicatesunits of articles (article IDs) that are available to ship by the depot115 are received into the inventory of the depot at operation 512.

At operation 514, a number of units (unit IDs) of articles (article IDs)for shipment to the site IDs are identified from the inventory of thedepot 115 based on supply plans associated with the site IDs. A messageis generated and transmitted to the shipper manager 113 of the depot 115to ship one or more shipments of identified unit IDs of Article IDs tothe site IDs at operation 516. At operation 518, the inventory for thedepot 115 is adjusted to reflect articles available to ship from thedepot 115 based on the identified unit IDs of Article IDs.

At operation 520, a determination is made as to whether the shipmentshave been shipped to the trial sites. Initially, shipment status of ashipment is “requested”. When a shipment is shipped by the shippermanager 113 from the depot 115, the inventory is updated to reflectshipment status and unit status to “in transit”. The shipper manager 113can also “dissolve” the shipment such that the shipment is marked as“dissolved” and items collected for shipment are marked as “available atdepot”. At operation 524, a further determination is made as to whetherthe shipment has been received. If it is determined that the shipmentwas received, then the shipment status is updated to “received” and unitstatus is updated to “available at site”. If it is determined that theshipment was not received, then the shipment status is updated to “lost”and unit status is updated to “wasted”. Thereafter, the method 500 endsat operation 532.

If it is determined that the shipment was not shipped at operation 520,then at operation 530, the shipment status is updated to “pendingshipment confirm”. Thereafter, the method 500 ends at operation 532.

FIG. 6 illustrates a flowchart of an example method 600 for randomizinga subject via randomizer 162 illustrated in FIG. 1. The method 600starts at operation 602 where the EDC 176 has enrolled a subject(subject ID) provided by a trial site (site ID), for example trial site114, into a clinical trial (trial ID). At operation 604, randomizationdata is received for a subject from the randomization CF 186 of the EDC176. The randomization data includes trial ID, site ID, subject ID, andstate of the subject for factors identified in the randomization design.At operation 606, the randomization design associated with the trial IDis retrieved, such as from the randomization and article database 154.

At operation 608, the subject (subject ID) is assigned to an arm (armID) of the clinical trial (trial ID) based on the randomization design.An example method of assigning (randomizing) the subject to the arm ofthe clinical trial is described in detail below with reference to FIG.7. More specifically, the randomization design is executed to assign thesubject ID to the arm ID of the trial ID. The trial ID, site ID, subjectID, arm ID, and states of factors are stored, such as in the runtimedatabase 158, at operation 610. Thereafter, at operation 612, arandomization indicator that indicates assignment of the subject(subject ID) is transmitted to the randomization CF 186 of the EDC 176.The method 600 ends at operation 614.

FIG. 7 illustrates a flowchart of an example method 700 for assigning asubject to an arm of a clinical trial. The example method 700 can beperformed by the randomizer 162 illustrated in FIG. 1. The method 700starts at operation 702 in which trial ID, site ID and subject ID areprovided from operation 608 of FIG. 6.

At operation 704, an overall trial imbalance in subject population isdetermined when the subject ID is treated hypothetically as if assignedto a selected arm (Arm ID) of the trial ID. A site imbalance isdetermined for the site (site ID) in the subject population when thesubject ID is assigned to the selected arm ID of the trial ID atoperation 706. At operation 708, a state imbalance is determined foreach factor in the subject population of the trial ID that shares thatstate with the subject ID. At operation 710, strata imbalance isdetermined in subject population that share the strata with subject ID.

Thereafter, at operation 712, a weighted sum of the imbalances for theselected arm (arm ID) is generated based on the randomization design.The weighted sum is saved temporarily for the selected arm ID. Atoperation 714, a determination is made as to whether there areadditional arms to process. If it is determined that there areadditional arms, then the method 700 performs operations 707-714 for theremaining arm IDs, saving temporarily the weighted sum of the imbalancesfor every processed arm ID.

If it is determined that there are no additional arms to process atoperation 714, then the method 700 continues at operation 716, where adetermination is made as to whether there is a set of two or more armIDs having the lowest weighted sum. If it is determined there aremultiple arms with the lowest weighted sum at operation 716, then thesubject ID is assigned randomly to an arm ID among the set of arm ID atoperation 718. Thereafter, the method 700 ends at operation 728.

However, if it is determined there is one arm with the lowest weightedsum at operation 716 then the method continues at operation 720, where adetermination is made as to whether a second best probability percentagehas been defined or set in the randomization design for the clinicaltrial. If the second best probability percentage has not been set atoperation 720, then the subject ID is assigned to the arm ID with thelowest weighted imbalance determined at operation 716.

Alternatively, if the second best probability percentage has been set atoperation 720, the method 700 continues at operation 724, where a set ofone or more arms (arm IDs) having a next lowest weighted imbalance isselected. At operation 726, the subject ID is assigned to an armrandomly from the one arm with the lowest weighted imbalance and the setof arms with the next lowest weighted imbalance based the second bestprobability percentage. For example, if the second best probabilitypercentage is set to 10%, the one arm with the lowest weighted imbalancewill be selected randomly 90% of the time, while an arm in the set withnext lowest weighted imbalance will be selected randomly 10% of thetime.

FIG. 8 illustrates a flowchart of an example method 800 for dispensingvia article dispenser 164 illustrated in FIG. 1. The method 800 startsat operation 802 where the EDC 176 has enrolled a subject (subject ID)provided by a trial site (site ID) into a clinical trial (trial ID) andhas randomized the subject ID into an arm (arm ID) of the trial ID viarandomizer 162 of FIG. 1. At operation 804, dispense data is receivedfor a subject from the dispense CF 188 of the EDC 176. The dispense dataincludes trial ID, site ID, subject ID, and visit ID associated with theclinical trial.

At operation 806, an arm (arm ID) is retrieved for the subject (subjectID) from the runtime database 158 indicating to which arm the subject isassigned. At operation 808, a treatment (set of one or more units of oneor more articles) is determined for the arm ID from the treatment designfor the clinical trial (Trial ID). At operation 810, a determination ismade as to whether there are sufficient units of articles at the site IDfor a treatment that complies with dispensation metrics for the site IDfrom the inventory in runtime database 158.

If it is determined that there are sufficient units, the set of units tobe dispensed to the subject ID is transmitted to the dispense CF 188 ofthe EDC 176. The trial site can dispense the identified units ofarticles to the subject indicated by the subject ID. At operation 814,inventory for the site ID is adjusted based on units dispensed to thesubject ID. The method 800 ends at operation 820.

However, if it is determined that there are insufficient units, amessage of “insufficient inventory” is transmitted to the dispense CF188 of the EDC 176 at operation 818. The trial site can then notify thetrial planner 110 or the shipper manger 113 of a depot concerning theinventory at the trial site. Other mitigation procedures may be invokedif there is a determination of inventory insufficiency at a trial site.The method 800 ends at operation 820.

FIG. 9 illustrates a flowchart of an example method 900 for randomizinga subject via the trial EDC 176 illustrated in FIG. 1. The method 900starts at operation 602 where a trial site (e.g., trial site 114) haslogged on via the trial administration system 104. At operation 904, atrial ID and a site ID are received from the trial administration system104 for the logged on trial site. At operation 906, the subject's statesfor factors required to randomize the subject in the clinical trial (perrandomization design) are received from the trial site (e.g., trial site114). Other information concerning the subject can also be received(e.g., name, contact information, as well as other information for theclinical trial).

At operation 908, the subject is assigned a subject ID. A new record forthe subject ID is added to the trial database 178. The record caninclude trial ID, site ID, states of the factors, as well as any otherinformation associated with the subject (subject ID).

At operation 912, it is determined whether randomization of the subjectID has been triggered, such as programmatically when certain inputrequirements for randomization are fulfilled or when randomization isuser-initiated. If not trigged, the method 900 waits until a trigger isreceived. Once randomization is triggered at operation 914, the trialID, site ID, subject ID and states of the factors are converted viarandomization CF 186 to RTSM randomization data.

At operation 916, the RTSM randomization data is transmitted to therandomizer 162 of the RTSM system 120. A randomization indicator thatindicates successful randomization is received from the randomizer 162at operation 918. The randomization indicator is stored to the recordfor the subject ID at operation 920. The method 900 ends at operation922.

FIG. 10 illustrates a flowchart of an example method 1000 for dispensingmedication to a subject via the trial EDC 176 illustrated in FIG. 1. Themethod 1000 starts at operation 1002 where a trial site (e.g., trialsite 114) has logged on via the trial administration system 104. Atoperation 1004, a trial ID, site ID, subject ID and visit ID associatedwith a clinical are received for a subject of the logged on trial site.

At operation 1006, a dispense trigger is received from the trial site,such as programmatically upon randomization of the subject viarandomization CF 186 for the first visit or via user-initiated input forsubsequent visits. If not trigged, the method 1000 waits until adispense trigger is received.

At operation 1008, a visit record (visit ID) and dispense indication areadded to the trial database 178 for the subject ID. At operation 1010,the trial ID, site ID, subject ID and visit ID are converted via adispense CF 188 to RTSM dispense data. The RTSM data is transmitted tothe article dispenser 164 of RTSM system 120 at operation 1012.

At operation 1014, a set of one or more unit indicators to be dispensedto the subject ID is received from the RTSM system 120. Thereafter, atoperation 1016, the dispensed set of unit indicators is stored to thevisit record for the subject ID. The method ends at operation 1018.

FIG. 11 illustrates an example webpage to configure a randomizationdesign for a clinical trial. The example webpage can be generated by therandomization designer 126 of the RTSM system 120. As illustrated in theweb page, the trial planner 110 can configure the number of arms in theclinical trial and ratio of subjects across the arms. The trial planner110 can further configure randomization factors and their weights forthe clinical trial. The trial planner 110 can also configured thesecond-best probability for randomization and strata associated with therandomization factors in the clinical trial.

FIG. 12 illustrates an example webpage to setup and simulate therandomization design for a clinical trial. The example webpage can begenerated by the simulation module 140 of the randomization simulator138. The simulations can be executed by the execution module 142. Thesimulation can be used to minimize the number of subjects in theclinical trial. Multiple simulations can be setup and simulated, asillustrated in FIG. 12.

FIG. 13 illustrates an example webpage to display simulation results ofone or more simulations executed in FIG. 12. The example webpage can begenerated by the results module 144 of the randomization simulator 138.The displayed results can include for each simulation executed, itssimulation metrics, start time and end time, total execution time.

FIG. 14A illustrates an example webpage to display aggregate subject armassignment within a particular run of a simulation. The example webpagecan be generated by the analysis module 146 of the randomizationsimulator 138. For a particular run shown in FIG. 14, in each of thesubject groups the following information is provided: i) a number ofsimulated subjects in that group that were assigned to each arm; ii) anabsolute value of the difference between that number and the totalnumber of subjects in that group, multiplied by a ratio of subjects thatshould be in each arm given the arm's weights; iii) whenever theabsolute value in (ii) is greater than 1, cells with imbalance areidentified.

As shown, the subject groups are: 1) subject population of the wholeclinical trial; 2) subject population of each trial site; 3) subjectsthat share a state of a factor (for each factor); and 4) subjects thatshare a stratum (for each stratum).

FIG. 14B illustrates an example webpage to display aggregate statisticalresults across runs of a randomization simulation. The aggregatestatistical analysis shows for each of the subject groups and each ofthe arms the mean and standard deviation as well as the minimum numberof the subjects from that subject group assigned to that arm. Inaddition, for each of the subject groups it shows the number of runsthat were out of balance.

FIG. 15 illustrates an example webpage to configure the treatment designfor a clinical trial. The example web page can be generated by thetreatment designer 148. The webpage enable definition of article typesand treatments for the clinical trial.

FIG. 16 illustrates an example webpage to manage article typesillustrated in FIG. 15. For a given article type illustrated in FIG. 15,dispensation metrics shown can be defined as illustrated in FIG. 16. Theexample web page can also be generated by the treatment designer 148.

FIG. 17A illustrates an example webpage generated for a clinical trialto manage one or more trial sites. The example webpage can be generatedby the site module 168. For each trial site, the webpage displays astudy name, trial site number (site ID), country, depot, supply plan,number of subjects randomized to the trial site, number of shipments tothe trial site, number of inventory items at the trial site, as well asshipping status. FIG. 17 further illustrates that a supply plan and/or adepot can be assigned to a trial site. Moreover, shipping can also beactivated/deactivated for the trial site.

FIG. 17B illustrates an example webpage to assign a supply plan to oneor more selected trial sites of the clinical trial. The trial sites forwhich the supply plan is to be updated (or changed) can be selected inFIG. 17A via check boxes illustrated next to the names of the trialsites. As illustrated in FIG. 17B, the “medium enrollers” supply plan ischosen and reflected for the selected “Balance study site 3” illustratedin FIG. 17A. As further illustrated in FIG. 17A, the “high enrollers”study plan was associated with the trial sites “site 1” and “site 2”.

FIG. 17C illustrates an example webpage to assign a depot to one or moreselected trial sites of the clinical trial. The trial sites for whichthe depot is to be updated (or changed) can be selected in FIG. 17A viacheck boxes illustrated next to the next to the names of the trialsites. As illustrated in FIG. 17C, the “EU Depot LTD. United Kingdom”depot is chosen and this depot is associated with the selected “Balancestudy site 3” illustrated in FIG. 17A.

FIG. 18 illustrates an example webpage generated for management ofsubjects in a clinical trial. The example webpage can be generated bythe subject module 170. For each subject ID, the webpage can includestratus, site, assigned study arm, and randomization time. Other detailcan be displayed for the subjects in the example webpage illustrated inFIG. 18.

FIG. 19 illustrates an example webpage for management of one or morearticle shipments in a clinical trial. The example webpage can begenerated by generated by the shipment module 172. Each shipment caninclude a name of the shipment, status, time status was changes, trialsite, depot, tracking number associated with shipment (is status is“shipped”), and units of articles (items of inventory).

FIG. 20 illustrates an example webpage for managing one or more items ofinventory in a clinical trial. The example webpage can be generated bygenerated by the inventory module 174. Each item is identified by anitem number and can include a status, trial site, depot, subject, visit,shipment, inventory batch to which the item belongs, article typeassociated with the item, sequence and location.

FIG. 21 illustrates an example webpage for managing an inventory batchlist for a clinical trial. These inventory batches are lists ofinventory items (e.g., collected in comma separated value (CSV) format)that a study manager 111 or shipper manager 113 can upload to the RTSMsystem 120. The inventory batch includes batch name, article type,expiry date, additional batch identifier, notes, depot, and number ofitems in the batch. When a list (or file) is uploaded RTSM system 120,the inventor module 174 processes the list and enters the articles aswell as associated information into the runtime database 158.

FIG. 22 illustrates an example webpage for managing logistics supplyplan. The example webpage illustrates the details of specific supplyplans and be used to add, change and delete supply plans. Two definedsupply plans are shown: medium enrollers and high enrollers. For eachplan, there can be defined a supply plan name, article type, minimalnumber of days between dispensing and expiration, minimal number of daysbetween shipping and expiration, initial trial site stocking level,trial site restocking threshold, trial site restocking level and numberof trial sites associated with the supply plan.

FIG. 23 is a block diagram of a general computer system 2300. Thecomputer system 2300 can include a set of instructions that can beexecuted to cause the computer system 2300 to perform any one or more ofthe methods or computer based functions disclosed herein with respect toFIGS. 1-22. The computer system 2300 or any portion thereof, may operateas a standalone device or may be connected (e.g., using a network 2324)to other computer systems or devices disclosed herein with respect toFIGS. 1-22. For example, the computer system 2300 can include or beincluded within any one or more of the computing devices or system inFIG. 1, or any other devices or systems disclosed herein with respect toFIGS. 1-22.

In a networked deployment, the computer system 2300 may operate in thecapacity of a server or a client machine in a server-client networkenvironment, or a peer machine in a peer-to-peer (or distributed)network environment. The computer system 2300 can also be implemented asor incorporated into various devices, such as a personal computer (PC),a tablet PC, a personal digital assistant (PDA), a web appliance, acommunications device, a mobile device, a wireless telephone, a server,a client or any other machine capable of executing a set of instructions(sequential or otherwise) that specify actions to be taken by thatmachine. Further, while a single computer system 2300 is illustrated,the term “system” shall also be taken to include any collection ofsystems or sub-systems that individually or jointly execute a set, ormultiple sets, of instructions to perform one or more computerfunctions.

As illustrated in FIG. 23, the computer system 2300 can include aprocessor 2302, e.g., a central processing unit (CPU), agraphics-processing unit (GPU), or both. Moreover, the computer system2300 can include a main memory 2304 and a static memory 2306 that cancommunicate with each other via a bus 2326. As shown, the computersystem 2300 may further include a video display unit 2310, such as aliquid crystal display (LCD), an organic light emitting diode (OLED), aflat panel display, a solid state display, or a cathode ray tube (CRT).Additionally, the computer system 2300 may include an input device 2312,such as a keyboard, and a cursor control device 2214, such as a mouse.The computer system 233300 can also include a disk drive unit 2316, asignal generation device 2322, such as a speaker or remote control, anda network interface device 2308.

In a particular embodiment, as depicted in FIG. 23, the disk drive unit2316 may include a machine or computer-readable medium 2218 in which oneor more sets of instructions 2320 (e.g., software) can be embedded.Further, the instructions 2320 may embody one or more of the methods orlogic as described herein with reference to FIGS. 1-22. In a particularembodiment, the instructions 2320 may reside completely, or at leastpartially, within the main memory 2304, the static memory 2306, and/orwithin the processor 2302 during execution by the computer system 2300.The main memory 2304 and the processor 2302 also may includecomputer-readable media.

In an alternative embodiment, dedicated hardware implementations, suchas application specific integrated circuits, programmable logic arraysand other hardware devices, can be constructed to implement one or moreof the methods described herein. Applications that may include theapparatus and systems of various embodiments can broadly include avariety of electronic and computer systems. One or more embodimentsdescribed herein may implement functions using two or more specificinterconnected hardware modules or devices with related control and datasignals that can be communicated between and through the modules, or asportions of an application-specific integrated circuit. Accordingly, thepresent system encompasses software, firmware, and hardwareimplementations.

In accordance with the various embodiments, the methods described hereinmay be implemented by software programs that are tangibly embodied in aprocessor-readable medium and that may be executed by a processor.Further, in an example, non-limited embodiment, implementations caninclude distributed processing, component/object distributed processing,and parallel processing. Alternatively, virtual computer systemprocessing can be constructed to implement one or more of the methods orfunctionality as described herein.

While the computer-readable medium is shown to be a single medium, theterm “computer-readable medium” includes a single medium or multiplemedia, such as a centralized or distributed database, and/or associatedcaches and servers that store one or more sets of instructions. The term“computer-readable medium” shall also include any medium that is capableof storing, encoding or carrying a set of instructions for execution bya processor or that cause a computer system to perform any one or moreof the methods or operations disclosed herein.

In a particular non-limiting, example embodiment, the computer-readablemedium can include a solid-state memory such as a memory card or otherpackage that houses one or more non-volatile read-only memories.Further, the computer-readable medium can be a random access memory orother volatile re-writable memory. Additionally, the computer-readablemedium can include a magneto-optical or optical medium, such as a diskor tapes or other storage device to capture carrier wave signals such asa signal communicated over a transmission medium. A digital fileattachment to an e-mail or other self-contained information archive orset of archives may be considered a distribution medium that isequivalent to a tangible storage medium. Accordingly, the disclosure isconsidered to include any one or more of a computer-readable medium or adistribution medium and other equivalents and successor media, in whichdata or instructions may be stored.

In accordance with various embodiments, the methods described herein maybe implemented as one or more software programs running on a computerprocessor. Dedicated hardware implementations including, but not limitedto, application specific integrated circuits, programmable logic arraysand other hardware devices can likewise be constructed to implement themethods described herein. Furthermore, alternative softwareimplementations including, but not limited to, distributed processing orcomponent/object distributed processing, parallel processing, or virtualmachine processing can also be constructed to implement the methodsdescribed herein.

It should also be noted that software which implements the disclosedmethods may optionally be stored on a tangible storage medium, such as:a magnetic medium, such as a disk or tape; a magneto-optical or opticalmedium, such as a disk; or a solid state medium, such as a memory cardor other package that houses one or more read-only (non-volatile)memories, random access memories, or other re-writable (volatile)memories. A digital file attachment to e-mail or other self-containedinformation archive or set of archives is considered a distributionmedium equivalent to a tangible storage medium. Accordingly, thedisclosure is considered to include a tangible storage medium ordistribution medium as listed herein, and other equivalents andsuccessor media, in which the software implementations herein may bestored.

Although the present specification describes components and functionsthat may be implemented in particular embodiments with reference toparticular standards and protocols, the invention is not limited to suchstandards and protocols. For example, standards for Internet and otherpacket switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP)represent examples of the state of the art. Such standards areperiodically superseded by faster or more efficient equivalents havingessentially the same functions. Accordingly, replacement standards andprotocols having the same or similar functions as those disclosed hereinare considered equivalents thereof.

Thus, a distributed clinical trial system has been described. Althoughspecific example embodiments have been described, it will be evidentthat various modifications and changes may be made to these embodimentswithout departing from the broader scope of the invention. Accordingly,the specification and drawings are to be regarded in an illustrativerather than a restrictive sense. The accompanying drawings that form apart hereof, show by way of illustration, and not of limitation,specific embodiments in which the subject matter may be practiced. Theembodiments illustrated are described in sufficient detail to enablethose skilled in the art to practice the teachings disclosed herein.Other embodiments may be utilized and derived therefrom, such thatstructural and logical substitutions and changes may be made withoutdeparting from the scope of this disclosure. This Detailed Description,therefore, is not to be taken in a limiting sense, and the scope ofvarious embodiments is defined only by the appended claims, along withthe full range of equivalents to which such claims are entitled.

Such embodiments of the inventive subject matter may be referred toherein, individually and/or collectively, by the term “invention” merelyfor convenience and without intending to voluntarily limit the scope ofthis application to any single invention or inventive concept if morethan one is in fact disclosed. Thus, although specific embodiments havebeen illustrated and described herein, it should be appreciated that anyarrangement calculated to achieve the same purpose may be substitutedfor the specific embodiments shown. This disclosure is intended to coverany and all adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, will be apparent to those of skill in theart upon reviewing the above description.

The Abstract is provided to comply with 37 C.F.R. §1.72(b) and willallow the reader to quickly ascertain the nature and gist of thetechnical disclosure. It is submitted with the understanding that itwill not be used to interpret or limit the scope or meaning of theclaims.

In the foregoing description of the embodiments, various features aregrouped together in a single embodiment for the purpose of streamliningthe disclosure. This method of disclosure is not to be interpreted asreflecting that the claimed embodiments have more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive subject matter lies in less than all features of asingle disclosed embodiment. Thus the following claims are herebyincorporated into the Description of the Embodiments, with each claimstanding on its own as a separate example embodiment.

1. A method of dispensing medication in a multi-arm clinical trial, themethod comprising: receiving, by a computing system, a subjectidentifier and a trial identifier from an electronic data capturesystem, the trial identifier indicating the multi-arm clinical trial,the subject identifier indicating a subject enrolled in the multi-armclinical trial; retrieving at runtime, by the computing system, an armidentifier from a database using the received subject identifierassociated with the trial identifier, the database storing a pluralityof subject identifiers associated with respective arm identifiers of aplurality of multi-arm clinical trials, the arm identifier indicating anarm in the multi-arm clinical trial to which the subject is assigned;and determining, by the computing system, from a second database atreatment for the arm using the arm identifier associated with the trialidentifier, the treatment based on a treatment design previouslyconfigured for the multi-arm clinical trial, the treatment including aset of one or more units of at least one article type, the seconddatabase storing a plurality of treatment designs associated with theplurality of multi-arm clinical trials.
 2. The method of claim 1,further comprising transmitting the set of one or more units to theelectronic data capture system.
 3. The method of claim 1, furthercomprising: uploading a batch of units of article types, the batchindicating units of article types available for shipment; and receivingan indication that one or more units of the at least one article typehave been received and are available at a trial site associated with thesubject identifier.
 4. The method of claim 3, further comprisingdetermining whether there are sufficient units of the at least onearticle type for the treatment at the trial site for the subjectidentifier that comply with dispensation metrics in the treatmentdesign.
 5. The method of claim 1, wherein the subject identifier and thetrial identifier are received from a dispense custom function of theelectronic data capture system.
 6. A system to dispense medication in amulti-arm clinical trial, the system comprising: a computing device; anda machine-readable medium comprising instructions that, when executed bythe computing device, cause the computing device to perform operationscomprising: receiving a subject identifier and a trial identifier froman electronic data capture system, the trial identifier indicating themulti-arm clinical trial, the subject identifier indicating a subjectenrolled in the multi-arm clinical trial; retrieving at runtime an armidentifier from a database using the received subject identifierassociated with the trial identifier, the database storing a pluralityof subject identifiers associated with respective arm identifiers of aplurality of multi-arm clinical trials, the arm identifier indicating anarm in the multi-arm clinical trial to which the subject is assigned;and determining from a second database a treatment for the arm using thearm identifier associated with the trial identifier, the treatment basedon a treatment design previously configured for the multi-arm clinicaltrial, the treatment including a set of one or more units of at leastone article type, the second database storing a plurality of treatmentdesigns associated with the plurality of multi-arm clinical trials. 7.The system of claim 6, wherein the operations further comprisetransmitting the set of one or more units to the electronic data capturesystem.
 8. The system of claim 6, wherein the operations furthercomprise: uploading a batch of units of article types, the batchindicating units of article types available for shipment; receiving anindication that one or more units of the at least one article type havebeen shipped and are available at a trial site associated with thesubject identifier.
 9. The system of claim 8, wherein the operationsfurther comprise determining whether there are sufficient units of theat least one article type for the treatment at the trial site for thesubject identifier that comply with dispensation metrics in thetreatment design.
 10. The system of claim 6, wherein the subjectidentifier and the trial identifier are received from a dispense customfunction of the electronic data capture system.
 11. A non-transitorymachine-readable storage medium comprising instructions that, whenexecuted by a processor, cause the processor to perform operationscomprising: receiving a subject identifier and a trial identifier froman electronic data capture system, the trial identifier indicating amulti-arm clinical trial, the subject identifier indicating a subjectenrolled in the multi-arm clinical trial; retrieving at runtime an armidentifier from a database using the received subject identifierassociated with the trial identifier, the database storing a pluralityof subject identifiers associated with respective arm identifiers of aplurality of multi-arm clinical trials, the arm identifier indicating anarm in the multi-arm clinical trial to which the subject is assigned;and determining from a second database a treatment for the arm using thearm identifier associated with the trial identifier, the treatment basedon a treatment design previously configured for the multi-arm clinicaltrial, the treatment including a set of one or more units of at leastone article type, the second database storing a plurality of treatmentdesigns associated with the plurality of multi-arm clinical trials. 12.The machine-readable storage medium of claim 11, wherein the operationsfurther comprise transmitting the set of one or more units to theelectronic data capture system.
 13. The machine-readable storage mediumof claim 11, wherein the operations further comprise: uploading a batchof units of article types, the batch indicating units of article typesavailable for shipment; and receiving an indication that one or moreunits of the at least one article type have been received and areavailable at a trial site associated with the subject identifier. 14.The machine-readable storage medium of claim 13, wherein the operationsfurther comprise determining whether there are sufficient units of theat least one article type for the treatment at the trial site for thesubject identifier that comply with dispensation metrics in thetreatment design.
 15. The machine-readable storage medium of claim 11,wherein the subject identifier and the trial identifier are receivedfrom a dispense custom function of the electronic data capture system.16. The method of claim 1, further comprising: receiving, by thecomputing system, a site identifier from the electronic data capturesystem, the site identifier indicating a trial site associated withtreatment in connection with the multi-arm clinical trial; transmittingthe set of one or more units to the electronic data capture system inconnection with dispensation of the set to the subject at the trial siteassociated with the site identifier.
 17. The system of claim 6, whereinthe operations further comprise: receiving a site identifier from theelectronic data capture system, the site identifier indicating a trialsite associated with treatment in connection with the multi-arm clinicaltrial; transmitting the set of one or more units to the electronic datacapture system in connection with dispensation of the set to the subjectat the trial site associated with the site identifier.
 18. Themachine-readable storage medium of claim 11, wherein the operationsfurther comprise: receiving a site identifier from the electronic datacapture system, the site identifier indicating a trial site associatedwith treatment in connection with the multi-arm clinical trial;transmitting the set of one or more units to the electronic data capturesystem in connection with dispensation of the set to the subject at thetrial site associated with the site identifier.